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[57] ABSTRACT 

A* method, for use in a mobile communications system 
having a plurality of mobile stations (MS's) and a mobile 
subscriber information register (MSIR), provides a request- 
ing MS with location information (LI) of a target MS. At a 
first step, a LI request signal, including a subscriber number 
assigned to the target MS, a service code representing a LI 
supplying service and a secret number, is received from the 
requesting MS. At a second step, it is checked whether the 
service code of the U supplying service is included in the 
subscriber information of the target MS stored in the MSIR, 
At a third step, if the service code of the LI supplying service 
is included in the subscriber information of the target MS, it 
is checked whether the secret numbers included in the 
subscriber information of the target MS and the LI request 
signal are identical each other. At a fourth step, if the secret 
numbers included in the subscriber information of the target 
MS and in the LI request signal are identical, the LI of the 
target MS is retrieved from the MSIR. At a fifth step, a 
current location of the target MS is checked. At a sixth step, 
it is checked whether the current location and the location 
represented by the retrieved U of the target MS are identical. 
At a final step, if the determination, result obtained in the 
sixth step is affirmative, the retrieved LI is sent to the 
requesting MS. 

6 Claims, 4 Drawing Sheets 
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METHOD FOR SUPPLYING SUBSCRIBER 
LOCATION INFORMATION IN A MOBILE 
COMMUNICATIONS SYSTEM 

FIELD OF THE INVENTION 5 

The present invention relates to a mobile communications 
system; and, more particularly, to a method for supplying a 
mobile station with information on subscriber location reg- 
istered in advance. 

BACKGROUND OF THE INVENTION 10 

As is well known, a mobile communications system 
(MCS) offers various services, such as a cellular phone 
service, a radio pager service and the like, to mobile sub- 
scribers connected to the MCS by radio. Basic components 15 
of the MCS comprise a plurality of mobile stations (MS's), 
a multiplicity of base station subsystems (BSS's), a number 
of mobile switching centers (MSCs) and a mobile sub- 
scriber information register (MSIR). 

A MS is a subscriber portable terminal assigned to a 20 
mobile subscriber. Each of the BSS's includes resources 
providing channels between each of the MSCs coupled 
thereto and the MS's within a service area thereof. Each of 
the MSCs is capable of handling voice and/or data trans- 
mitted from the subscribers connected thereto. Each of the 25 
MSCs is coupled to a transit network (TN), the TN com- 
prising one or more electronic switching systems to be used 
for relaying voice and/or data between a public switched 
telephone network (PSTN) (not shown) and each of the 
MSCs and between the MSCs. 30 

The MSIR registers subscriber information for the mobile 
subscribers. The MSIR is connected to each of the MSCs 
through the TN. The subscriber information for each of the 
mobile subscribers includes a subscriber number, subscriber 
data (SD), and location information (U). The SD includes 35 
services available to each of the mobile subscribers. The LI 
represents a location where a MS assigned to each of the 
mobile subscribers has performed a last location registra- 
tion. The LI is registered in a predetermined format 
including, e.g., a MS location parameter of latitude, longi- 40 
tude and resolution information. 

The LI of the conventional MCS described above, 
however, is dedicated in positioning the MS's by the MCS 
and cannot be accessed by an individual subscriber. As a 
result, when a mobile subscriber wants the location of the 45 
MS of another mobile subscriber, it will be necessary to set 
up a call with the MS to find out the location thereof, even 
though the LI of the MS of the other mobile subscriber is 
registered in the MSIR. 

SUMMARY OF THE INVENTION 50 

It is, therefore, a primary object of the present invention 
to provide a method for use in a MCS for capable of 
supplying a MS with the LI of another MS. 

In accordance with the present invention, there is pro- 55 
vided a method, for use in a MCS having a plurality of MS's 
and a MSIR, for providing a requesting MS with LI of a 
target MS, wherein the MSIR stores subscriber information 
for each MS, the subscriber information for the target MS 
including a subscriber number and the LI of the target MS, 60 
service codes representing services available to the target 
MS and a secret number, comprising the steps of: 

(a) receiving from the requesting MS a LI request signal, 
wherein the LI request signal includes a subscriber 
number assigned to the target MS, a service code 65 
representing a LI supplying service and a secret num- 
ber; 
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(b) checking whether the service code of the LI supplying 
service is included in the subscriber information of the 
target MS stored in the MSIR; 

(c) if the service code of the LI supplying service is 
included in the subscriber information of the target MS, 
checking whether the secret number included in the 
subscriber information of the target MS and that 
included in the LI request signal are identical each 
other; 

(d) if the secret numbers included in the subscriber 
information of the target MS and in the LI request 
signal are identical, retrieving the LI of the target MS 
from the MSIR; 

(e) checking a current location of the target MS; 

(f) determining whether the current location and the 
location represented by the retrieved LI of the target 
MS are identical; and 

(g) if the determination result obtained in step (f) is 
affirmative, sending the retrieved LI to the requesting 
MS as the current U of the target MS. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects and features of the present 
invention will become apparent from the following descrip- 
tion of preferred embodiments given in conjunction with the 
accompanying drawings, in which: 

FIG. 1 presents a schematic block diagram of a MCS; 

FIG. 2 shows an exemplary format of a MS location 
parameter; and 

FIGS. 3A and 3B provide flow charts illustrating the 
procedure for supplying the LI in accordance with the 
present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

Referring to FIG. 1, there is provided a block diagram of 
a MCS 100. The MCS 100 comprises a plurality of mobile 
stations (MS's) 10-1 to 10-2, a multiplicity of base station 
subsystems (BSS's) 20-1 to 20-2, a plural number of mobile 
switching centers (MSCs) 30-1 to 30-2 and a mobile 
subscriber information register (MSIR) 40. For the sake of 
illustration, the inventive method will be described with 
reference to two MSCs 30-1 and 30-2 selected from a 
plurality of MSCs within the MCS 100, two BSS's 20-1 and 
20-2 chosen from multiple BSS's coupled with the MSC 
30-1 and from multiple BSS's coupled with the MSC 30-2, 
respectively, and two MS's 10-1 and 10-2 out of those 
coupled with the BSS's 20-1 and 20-2, respectively, through 
a radio interface. 

A MS is a subscriber portable terminal assigned to a 
mobile subscriber. The BSS's 20-1 and 20-2 include 
resources providing a channel between the MSC 30-1 and 
the MS 10-1 and the one between the MSC 30-2 and the MS 
10-2, respectively. The MSCs 30-1 and 30-2 are capable of 
handling voice and/or data transmitted from the subscribers 
connected thereto. Each of the MSCs 30-1 and 30-2 is 
coupled to a transit network (TN) 40, the TN 50 comprising 
one or more electronic switching systems to be used for 
relaying voice and/or data between a public switched tele- 
phone network (PSTN) (not shown) and each of the MSCs 
30-1 and 30-2 and,between the MSCs 30-1 and 30-2. 

The MSIR 40 registers subscriber information for the 
mobile subscribers. The MSIR 40 is connected to each of the 
MSCs 30-1 and 30-2 through the TN 50. The subscriber 
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information for each of the mobile subscribers includes a 
subscriber number, location information (LI) and subscriber 
data (SD). The LJ of a MS may be represented by the 
location of a BSS when the MS is positioned within the 
service area of the BSS. Since the identification of the BSS 
to which the MS belongs or the registration of the LI for the 
MS can be made in a conventional manner by the signalling 
between the MS and the BSS and a handoff process, details 
thereof will not be described here for the sake of simplicity. 
In another instance, if an absolute location of the MS can be 
detected, the U of the MS can be represented by a MS 
location parameter of a latitude, a longitude and a resolution 
and is registered in a predetermined format as shown in FIG. 
2. Referring to FIG. 2, there is illustrated the format of the 
MS location parameter representing the location of the MS. 
As shown in FIG. 2, the length of the location parameter is 
7 octets. 3 octets are used for representing the latitude 
information of the MS. And another 3 octets are used for 
representing the longitude information of the MS, And the 
remaining 1 octet is used for representing the resolution 
information for the latitude and the longitude location mea- 
surements. 

The latitude and the longitude information fields are 
signed integers specifying the estimated MS location in unit 
of tenth of a second. The range of the latitude is ±324,000 
seconds; the range of the longitude is ±648,000 seconds. A 
positive latitude implies a North latitude; a positive longi- 
tude implies a West longitude. A negative value is repre- 
sented in a form of the 2's complement. 

The resolution information field is expressed in foot, 
wherein the MS will be located, in, e.g., 90% confidence 
level, within a circle centered at the latitude and the longi- 
tude whose radius is given by the resolution information. 

The SD includes service codes representing services 
available to each of the mobile subscribers. When the mobile 
subscriber registers on the U supplying service, a service 
code representing the LI supplying service and a secret 
number are included in the SD. In other words, when a 
requesting mobile subscriber (RQ) requests the LI of a target 
MS assigned to a target mobile subscriber (TG) registered on 
the LI supplying service, the LI of the target MS is provided 
only to the RQ who can provide the secret number of the TG. 

Referring back to FIG. 1, when the RQ requests the LI of 
the target MS, the RQ inputs a LI request signal including a 
service code representing the LI supplying service and the 
subscriber and the secret numbers for the target MS. The RQ 
may request the LI of his own MS, i.e., the subscriber 
number of the target MS may be same as that for the RQ. For 
the sake of the illustration, it is assumed that the RQ is the 
mobile subscriber of the MS 10-1 and the target MS is the 
MS 10-2. 

The LI request signal is transmitted from the MS 10-1 via 
the radio interface to the BSS 20-1. As is well known in the 
art, the BSS 20-1 performs a conventional radio frequency 
signal processing and a signal format conversion from the 
format of the MS 10-1 to that of the MSC 30-1. And then, 
the LI request signal from the MS 10-1 is finally received by 
the MSC 30-1 through the BSS 20-1. 

In response to the LI request signal, the MSC 30-1 
retrieves the SD of the target MS 10-2 registered in the 
MSIR 40 to check whether or not the target MS 10-2 is 
registered for the LI supplying service, i.e., the LI supplying 
service code is included in the SD of the MS 10-2. 

Then, the MSC 30-1 compares the secret number from the 
MS 10-1 with the secret number in the SD of the MS 10-2 
to check whether or not the two numbers are identical each 
other; and then the MSC 30-1 retrieves the LI of the MS 
10-2. 
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If the LI represents, for example, that the MS 10-2 is 
located within reach of the BSS 20-2, the MSC 30-1 requests 
the MSC 30-2 to check whether or not the MS 10-2 is within 
reach thereof and also whether or not its power is on 

5 currently. For example, the MSC 30-1 sends a location 
confirmation request signal to the MSC 30-2. The MSC 30-2 
confirms the location of the MS 10-2 using a conventional 
order procedure which requests a response from the MS 
10-2. When the response is received from the MS 10-2, the 

10 MSC 30-2 sends a location confirmation signal to the MSC 
30-1. When the MSC 30-1 receives the location confirma- 
tion signal, the MSC 30-1 sends the LI of the MS 10-2 to the 
MS 10-1 through the BSS 20-1. The MS 10-1 may be 
constructed to display the location of the MS 10-2 on a 

15 display thereof based on the LJ of the MS 10-2. 

Referring to FIGS. 3A and 3B, there is illustrated a 
procedure for supplying the location information in accor- 
dance with the present invention. 

At step S3 1, the inventive process is initiated, e.g., when 

20 the LI request signal including the service code representing 
the LI supplying service, the subscriber number and the 
secret number of the MS 10-2 is provided from the MS 10-1 
to the MSC 30-1 through the BSS 20-1. At step S32, the 
MSC 30-1 retrieves the SD of the target MS 10-2 stored in 

25 the MSIR 40 and the process proceeds to step S33. 

At step S33, the MSC 30-1 checks if the service code is 
included in the SD of the target MS 10-2. If the service code 
is included in the SD of the MS 10-2, the process goes to 

3Q step S35; but if not, it proceeds to step S34, wherein the 
MSC 30-1 sends a service code failure signal to the MS 
10-1, and the process is terminated. The service code failure 
signal represents a voice or an image signal capable of 
informing the RQ of the MS 10-1 that the service cannot be 

35 provided because the target MS is not registered for the LI 
supplying service. 

At step S35, the secret number received from the MS 10-1 
is compared with the secret number of the target MS 10-2, 
registered in the MSIR 40. If the two numbers are identical, 

40 the process goes to step S37 in FIG. 3B; otherwise, it 
proceeds to step S3 6, wherein the MSC 30-1 sends a secret 
number failure signal to the MS 10-1, and the process is 
terminated. The secret number failure signal represents a 
voice or an image signal capable of informing the RQ of the 

45 MS 10-1 that the LI supplying service cannot be provided 
because the received secret number is not identical to the one 
registered in the MSIR 40. 

At step S37 shown in FIG. 3B, the MSC 30-1 retrieves the 
LJ of the MS 10-2 stored in the MSIR 40 and traces a BSS, 

50 e.g., the BSS 20-2, indicated by the LI of the target MS 10-2. 
After determining the BSS corresponding to the LI, the MSC 
30-1 further decides a MSC, e.g., the MSC 30-2, coupled 
with the determined BSS 20-2. At step S38, the MSC 30-1 
generates a location confirmation request signal to the MSC 

55 30-2 and goes to step S39. 

At step S39, the MSC 30-1 waits for the location confir- 
mation signal from the MSC 30-2 for a predetermined time 
period. If the location confirmation signal is received by the 
MSC 30-1 within the predetermined time period, the process 

60 goes to step S41; otherwise, the process proceeds to step 
S40, wherein the MSC 30-1 sends a location confirmation 
failure signal to the MS 10-1 via the BSS 20-1 and proceeds 
to step S41. The location confirmation failure signal repre- 
sents a voice or an image signal capable of informing the RQ 

65 of the MS 10-1 that the LI to be provided represents the 
latest location of the MS 10-2 and that the target MS 10-2 
is out of reach or its power is off currently. At step S41, the 
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MSC 30-1 sends the LI of the MS 10-2 to the MS 10-1 as 
current location information of the target MS 10-2; and the 
process terminates. 

While the present invention has been shown and 
described with respect to the particular embodiments, it will 5 
be apparent to those skilled in the art that many changes and 
modifications may be made without departing from the spirit 
and scope of the invention as defined in the appended 
claims. 

What is claimed is: 10 

1. A method, for use in a mobile communications system 
having a plurality of mobile stations (MS's) and a mobile 
subscriber information register (MSIR), for providing a 
requesting MS with location information of a target MS, 
wherein the MSIR stores subscriber information for each 15 
MS, the subscriber information for the target MS including 

a subscriber number and the location information of the 
target MS and service codes representing services available 
to the target MS, the method comprising the steps of: 

(a) receiving from the requesting MS a location informa- 20 
tion request signal, wherein the location information 
request signal includes a subscriber number assigned to 
the target MS and a service code representing a location 
information supplying service; 

(b) checking whether the service code representing the 
location information supplying service is included in 
the subscriber information of the target MS stored in 
the MSIR; 

(c) if the service code representing the location informa- 30 
tion supplying service is included in the subscriber 
information of the target MS, retrieving the location 
information of the target MS from the MSIR; 

(d) checking a current location of the target MS; 

(e) determining whether the current location and the 35 
location represented by the retrieved location informa- 
tion of the target MS are identical; and 

(f) if the determination result obtained in step (e) is 
affirmative, sending the retrieved location information 

to the requesting MS as the current location informa- 40 
tion of the target MS. 

2. The method of claim 1, further comprising, after the 
step (c), the step of (cl) if the service code representing the 
location information supplying service is not included in the 
subscriber information of the target MS, sending a service 45 
code failure signal to the requesting MS. 

3. The method of claim 2, further comprising, after the 
step (f), the step of: (g) if the determination result obtained 
in the step (e) is negative, sending a location confirmation 
failure signal and the retrieved location information to the 50 
requesting MS. 

4. A method, for use in a mobile communications system 
having a plurality of mobile stations (MS's) and a mobile 
subscriber information register (MSIR), for providing a 
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requesting MS with location information of a target MS, 
wherein the MSIR stores subscriber information for each 
MS, the subscriber information for the target MS including 
a subscriber number and the location information of the 
target MS, service codes representing services available to 
the target MS and a secret number, the method comprising 
the steps of: 

(a) receiving from the requesting MS a location informa- 
tion request signal, wherein the location information 
request signal includes a subscriber number assigned to 
the target MS, a service code representing a location 
information supplying service and a secret number; * 

(b) checking whether the service code of the location 
information supplying service is included in the sub- 
scriber information of the target MS stored in the 
MSIR; 

(c) if the service code of the location information sup- 
plying service is included in the subscriber information 
of the target MS, checking whether the secret number 
included in the subscriber information of the target MS 
and that included in the location information request 
signal are identical each other; 

(d) if the secret numbers included in the subscriber 
information of the target MS and in the location infor- 
mation request signal are identical, retrieving the loca- 
tion information of the target MS from the MSIR; 

(e) checking a current location of the target MS; 

(f) determining whether the current location and the 
location represented by the retrieved location informa- 
tion of the target MS are identical; and 

(g) if the determination result obtained in step (f) is 
affirmative, sending the retrieved location information 
to the requesting MS as the current location informa- 
tion of the target MS. 

5. The method of claim 4, further comprising, after the 
step (c), the steps of: 

(cl) if the service code of the location information sup- 
plying service is not included in the subscriber infor- 
mation of the target MS, sending a service code failure 
signal to the requesting MS; and 

(c2) if the secret numbers included in the subscriber 
information of the target MS and in the location infor- 
mation request signal are not identical each other, 
sending a secret number failure signal to the requesting 
MS. 

6. The method of claim 5, further comprising, after step 
(g), the step of: (h) if the determination result obtained in 
step (f) is negative, sending a location confirmation failure 
signal and the retrieved location information to the request- 
ing MS. 

* * * * * 



12/27/2002, EAST Version: 1.03.0002 



llllllllllllMllllilllllllllll 

US0O62983O7B1 

(12) United States Patent (k» Patent No.: us 6,298,307 bi 

Murphy et al. (45) Date of Patent: Oct 2, 2001 



(54) USER SPECIFIC REAL-TIME WEATHER 

INFORMATION SOURCE FOR COMPILING 
TIME VARYING WEATHER CONDITIONS 
RELATING TO FUTURE EVENT 

(75) Inventors: John M. Murphy, Westminster; Wayne 
Crosby Moore, Longmont; Robert 
Keith Barron, Boulder, all of CO (US) 

(73) Assignees: University Corporation for 

Atmospheric Research; WITI 
Corporation, both of Boulder, CO (US) 

( * ) Notice: This patent issued on a continued pros- 
ecution application filed under 37 CFR 
1.53(d), and is subject to the twenty year 
patent term provisions of 35 U.S.C. 
154(a)(2). 

Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C 154(b) by 0 days. 

(21) Appl. No.: 08/960,296 

(22) Filed: Oct. 29, 1997 

(51) Int. CI. 7 G06F 17/30 

(52) U.S. CI 702/3; 702/2; 707/10; 

707/104 

(58) Field of Search 707/1-6, 8-10, 

707/100-104, 200-203; 395/200.49; 379/74, 
84, 87, 101.1, 93.09; 704/275, 9; 342/26, 
352, 192, 84; 706/20, 902, 930-931; 705/10, 
14, 15; 702/2-4, 5 

(56) References Cited 

U.S. PATENT DOCUMENTS 

4,450,477 5/1984 Lovett 348/7 

4,521,857 6/1985 Reynolds, III 379/88.17 

5,132,992 7/1992 Yurt et al 375/240 

5,253,275 10/1993 Yurt et al 375/240 

5,265,024 11/1993 Crabill et al 701/200 

5,390,237 * 2/1995 Hoffman, Jr. et al 379/88.23 

5,410,343 4/1995 Coddington et al 348/7 



5,475,587 12/1995 Anick et al 704/9 

5,517,193 * 5/1996 Allison et al 342/26 

5,654,886 ♦ 8/1997 Zereski, Jr. et al 702/3 

5,717,589 * 2/1998 Thompson et al 702/3 

5,740,549 * 4/1998 Reilly et al 705/14 

5,793,813 • 8/1998 Cleave 375/259 

5,796,932 * 8/1998 Fox et al 395/161 

5,796,945 * 8/1998 Tarabella 395/200.49 

5,909,671 * 6/1999 Byford et al 705/26 

5,940,776 * 8/1999 Baron et al 702/4 

6,018,699 ♦ 1/2000 Baron, Sr. et al 702/3 

* cited by examiner 

Primary Examiner— Jack Choules 
Assistant Examiner— Sriraima Channavajjala 

(57) ABSTRACT 

The best-in-time forecasting system customizes its output 
forecast to the specific needs of a user and an identified 
event, which forecast is optimized as a function of the length 
of time between the receipt of the request and the time of the 
event. The best-in-time forecasting system comprises a data 
ingest & assimilation system that obtains the time-varying 
phenomena characteristic data from a plurality of external 
data sources and processes this information into a form and 
content appropriate for the needs of the best -in- time fore- 
casting system. The processed data is stored in an informa- 
tion server for use by a presentation content system which 
functions to receive, process and respond to the user- 
provided information requests. A plurality of databases are 
included in the presentation content system to provide a 
subset of the time-varying characteristic data that the phe- 
nomena forecaster requires to process the forecast request. A 
user preferences database is an optional component of this 
database and functions to record the past activity of the user 
to enable the best-in-time forecasting system to provide 
user-customized responses. An activity database provides 
information relating to a definition of the various activities 
which are supported by the best-in-time forecasting system. 
The activity data notes the time-varying characteristics that 
are relevant to this activity so that the presentation content 
system can customize the data stored in the time-varying 
phenomena characteristic information database as a function 
of the event. 

16 Claims, 5 Drawing Sheets 
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USER SPECIFIC REAL-TIME WEATHER best-in-time forecasting system comprises a data ingest & 

INFORMATION SOURCE FOR COMPILING assimilation system that obtains the time-varying phenom- 

TIME VARYING WEATHER CONDITIONS ena characteristic data from a plurality of external data 

RELATING TO FUTURE EVENT sources and processes this information into a form and 

5 content appropriate for the needs of the best-in-time fore- 

F1ELD OF THE INVENTION casting system. The processed data is stored in an informa- 

r . . lion server for use by a presentation content system which 

This invention relates to forecasting systems, and in tQ receivej process aQd respood to ^ ^ 

particular to a best-in-time forecasting system for on provided information requests. A plurality of databases are 
demand forecasting the time-varying characteristics of a 1Q ^ tfae 5^.^^ forecast ing system, one of 
phenomena as they relate to a user-identified future event whicfa i(Jes a subset of ^ time . varying characteristic 
that is to take place at an identified locus. The present dm (hat the phenomena forecaster requires to process the 
best-in-time forecasting system customizes the forecast pro- forecast t This database contains the previously pro- 
vided to the user as a function of the users information cessed results ^ tQ the time-varying phe- 
preferences, the type of activity specified by the user, and the J5 nomeQa characteristic information. A user preferences data- 
length of time between the receipt of the request and the time base fa aQ oplional ^p^^ of mis dalabase and functions 
of the event. to recor d toe pasl act ivity of the user to enable the best-in- 
p , . time forecasting system to provide user-customized 
ro em responses. An activity database provides information relat- 
It is a problem in the field of forecasting to assimilate the 20 ing to a definition of the various activities which are sup- 
plethora of information that relates to the time-varying ported by the best-in-time forecasting system . The activity 
characteristics of monitored phenomena and provide users, data notes the time-varying characteristics that are relevant 
on demand, with an accurate forecast of specific character- to this activity so that the presentation content system can 
istics of the phenomena that can be expected to be present customize the data stored in the time-varying phenomena 
at a defined locus and future time identified by the user. A 25 characteristic information database as a function of the 
further problem is that existing forecasting systems cannot event. 

customize the forecast provided to the user as a function of The present best-in-time forecasting system is illustrated 
the user's information preferences, the type of event speci- as a weather forecasting system that provides a user with 
fied by the user, and the length of time between the receipt weather information that is customized to the specific needs 
of the request and the time of the event. 30 of a user and an identified event, which forecast is also 
A typical forecasting application is the provision of optimized as a function of the length of time between the 
weather forecasts to members of the general public. The receipt of the request and the time of the event. In operation, 
users who request weather forecast information have vary- a user provides the best-in-time forecasting system with data 
iog interests, different levels of understanding of the indicative of the time, date, place for the forecast as well as 
received forecasts, and different modes of communicating 35 the type of activity that the user wishes to participate in on 
with the forecasting system. Similarly, the activity of interest the identified time and date. Regardless of the information 
to the user has unique characteristics that effect the type of provided by the user, the best -in-time forecasting system 
weather information that must be provided to the user. generates a response, with the thoroughness and accuracy of 
Finally, the user should be provided with the most accurate the response being a function of the specificity of the 
information that is presently available for forecasting the 40 user-provided information and the length of time between 
desired weather characteristics, which data may be available the present time and the event occurrence. The user's request 
from a multitude of sources, each having different degrees of stimulates the best-in-time forecasting system to identify the 
accuracy as a function of the length of time between the set of resources that are available to the best-in-time fore- 
receipt of the request and the time of the event. Existing casting system that can be used to provide the user-requested 
weather forecasting systems are unable to provide forecasts 45 information. In the present weather forecasting system 
that are customized to reflect these above-noted factors. The example, the information can be purely climate data or a 
existing weather forecasting systems simply provide an blending of real-time and weather forecast data sources. The 
output that is immutable in format and type of content, forecast can also be tailored to the specific activity identified 
regardless of the needs of the user. Each weather forecasting by the user. The user-provided data can include threshold 
system is designed to provide a certain level of information, 50 data which causes the best-in-time forecasting system to 
and is typically designed for a predefined audience, who generate a notification of the user if certain parameters are 
have certain weather information needs. mcl or exceeded. The best-in-time forecasting system can 
Urns, there presently does not exist a forecasting system, *cn ^ lhc user via a communication medium through 
especially a weather forecasting system, that can customize <e whlch the user . * connected to the best-in-time forecasting 
its output forecast to the specific needs of a user and an 55 *Y**™ 10 P^* l a havm 8 : a ^"mattbat 
identified event, which forecast is optimized based upon the arc customized for the user-specific request Tlic request 
length of time between the receipt of the request and the time ma y ori g uiate via uscr ^calendar and scheduling software, 
of the event project management software, an events scheduler or by 

completing a best-in-time forecasting system provided 
60 screen. 



Solution 



BRIEF DESCRIPTION OF THE DRAWING 



The present best-in-time forecasting system overcomes 

the problems of the prior art and provides a forecasting FIG. 1 illustrates in block diagram form the overall 

system that can customize its output forecast to the specific architecture of the present best-in-time forecasting system; 

needs of a user and an identified event, which forecast is 65 FIG. 2 illustrates in block diagram form additional details 

optimized as a function of the length of time between the of the Weather Data Ingest & Assimilation system of the 

receipt of the request and the time of the event. The present best-in-time forecasting system; 
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FIG. 3 illustrates in block diagram form additional details 
of the Weather Information Server system of the present 
best-in-time forecasting system; 

FIG. 4 illustrates in block diagram form additional details 
of the phenomena forecaster of the present best-in-time 5 
forecasting system; and 

FIGS. 5 A and 5B illustrate in flow diagram form the 
operation of the present best-in -time forecasting system in 
customizing the forecast for an identified user and this user's 
specific forecast request. 10 

DETAILED DESCRIPTION 

FIG. 1 illustrates in block diagram form the overall 
architecture of the resent best -in-time forecasting system 
100. The best- in -time forecasting system 100 provides on 15 
demand forecasting of the time -varying characteristics of a ' 
phenomena as they relate to a user- identified future event 
that is to take place at an identified locus. The present 
best-in-time forecasting system 100 customizes the forecast 
provided to the user as a function of the user's information 20 
preferences, the type of activity specified by the user, and the 
length of time between the receipt of the request and the time 
of the event. 

The particular example of the best-in-time forecasting 
system illustrated herein is a meteorological information 25 
processing system that provides weather forecast data to 
requesting users. The best-in-time forecasting system 100 
comprises a plurality of operational segments, one of which 
(weather data ingest & assimilation system 101) functions to 
provide the data ingest and assimilation functions to obtain 30 
the time-varying phenomena characteristic data from a plu- 
rality of external Data Sources 111—113. The best-in-time 
forecasting system 100 is connected to at least one and 
preferably a plurality of Data Sources 111-113 from which 
the best-in-time forecasting system 100 obtains the infor- 35 
mation which it processes to respond to user-provided 
information requests. The best-in-time forecasting system 
100 also includes a Weather Information Server 102 that 
functions to store the processed time-varying phenomena 
characteristic data in memory in a manner that enables the 40 
best-in-time forecasting system 100 to provide responses to 
the requesting users. The best-in-time forecasting system 
100 also includes a Presentation Content System 103 which 
functions to receive, process and respond to the user- 
provided forecast requests. A plurality of databases (shown 45 
in FIG. 4) are included in the Presentation Content System 
103 of best-in-time forecasting system 100, one of which 
(time -varying phenomena characteristic information data- 
base 411) provides a subset of the time-varying character- 
istic data that the Presentation Content System 103 requires 50 
to process the forecast request. This database contains the 
basic raw data and previously processed results relating to 
the user-desired time-varying phenomena characteristic 
information. A User Preferences Database 412 is an optional 
component and functions to record the past activity of the 55 
user to enable the best-in-time forecasting system 100 to 
provide user-customized responses. An Activity Database 
413 provides information relating to a definition of the 
various activities which are supported by the best-in-time 
forecasting system 100. The activity data notes the time- 60 
varying characteristics that are relevant to this activity so 
that the Presentation Content System 103 can customize the 
data stored in the time-varying phenomena characteristic 
information database as a function of the event Finally, an 
Alarm Process 414 is provided to monitor various user- 65 
defined and/or predefined thresholds to generate alerts to the 
users, as requested or as related to their forecast queries. 
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The best-in-time forecasting system 100 is also typically 
connected to a communication medium, such as a Network 
104 which serves to interconnect the best-in-time forecast- 
ing system 100 with a plurality, of users. The Network 104 
functions as a switched point-to-point communication sys- 
tem to enable a user to input a request for forecast infor- 
mation to the best-in-time forecasting system 100 and 
receive forecast information therefrom. 

The best-in-time forecasting system 100 therefore inter- 
connects with a plurality of Data Sources 111-113 which 
typically comprise a diversity of meteorological data pro- 
cessing systems in order that the data collected by these 
systems can be used in an integrated manner to provide data 
to users who have specific data retrieval needs which, in 
many cases, are inconsistent with the form, format and 
content of the data produced by the various meteorological 
data processing systems. A plurality of meteorological data 
processing systems are illustrated as connected to the best- 
in-time forecasting system 100, although one or more of 
these meteorological data processing systems can be incor- 
porated into the best-in-time forecasting system 100 without 
departing from the conceptual architecture that is disclosed 
herein. The various meteorological data processing systems 
comprise systems that collect data from various sensors, 
which data is indicative of a present value or a forecasted 
value of a predetermined meteorological characteristic or 
phenomena. The data so collected is then processed in well 
known manner by the processing element contained within 
the meteorological data processing system to convert the 
collected raw data into a human understandable display of 
the characteristics of the meteorological phenomena that are 
of interest to the user. The output display information is 
transmitted from each of the meteorological data processing 
systems to the best-in-time time forecasting system 100 as 
well as, in certain cases, the unprocessed or partially pro- 
cessed data obtained from the sensors which serve this 
particular meteorological data processing system. The 
present best-in-time forecasting system weather database 
therefore typically contains basic raw data, weather products 
and previously processed results relating to weather infor- 
mation. 

Weather Data Ingest & Assimilation System 

The Weather Data Ingest & Assimilation System 101, 
shown in additional detail in FIG. 2, is responsible for the 
ingest of raw data from numerous data sensors and Data 
Sources 111-113, including the National Weather Service 
radar and satellites. Each of the raw data streams generated 
by these Data Sources 111-113 may require assimilation in 
both space and time, and must be formatted in a manner to 
be properly interpreted by the Data Interface 301 element 
(shown in FIG. 3) of the Weather Information Server 102. 
Therefore, the Weather Data Ingest & Assimilation System 
101 includes Ingest Elements 201-203, each of which 
functions as the physical interface to receive the data output 
by an associated one of Data Sources 111-113. This received 
raw data is forwarded by the Ingest Elements 201-203 to 
associated Assimilation Elements 211-213 which convert 
the raw data into a form and content that is usable by the 
Weather Information Server 102. 
Data Sources 

The plurality of Data Sources 111-113 that are connected 
to the Weather Data Ingest & Assimilation System 101 can 
include data received from the National Weather Service and 
data from private vendors. The data from the National 
Weather Service family of services can include: METAR 
Surface Data, and NGM MOS Data. The data received from 
each of these sources have characteristics and content that 
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are specific to the particular data source. Therefore, the 
received data from a plurality of Data Sources 111-113 must 
typically used to satisfy a user presented information 
request. The following examples indicate two typical data 
streams obtained from presently available Data Sources. 
An example of NGM MOS data is: 



received data is stored in a multidimensional database (Data 
Store 302) that contains all of the weather information 
presently available for the sites that are maintained in the 
best-in-time forecasting system 100. This data is formatted, 
inventoried and addressed by the Data Interface 301 portion 
of the Weather Information Server 102. In addition, an 



FOUSH KWBC 280000 

ABE EC NGM MOS GUIDANCE 8/26/97 0000 UTC 
DAY/AUG26 /AUG27 /AUG28 

HOUR 06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
MX/MN 80 62 80 64 

TEMP 64 62 63 72 78 78 73 68 65 63 65 73 77 77 73 69 67 65 66 

DEWPT 60 60 60 61 60 60 61 61 62 62 63 64 63 62 63 64 64 63 63 

CLDS BK BK OV BK BK BK BK BK BK OV OV BK BK BK BK BK BK BK 

SC 

WDIR 05 04 06 12 18 17 18 20 21 08 15 20 20 20 20 20 20 26 23 
WSPD 04 04 02 03 04 05 04 05 05 04 04 06 09 08 07 05 05 04 05 



16 



POP06 19 6 21 4 7 10 
POP12 27 11 23 33 

QPF 01 0/ 0/0 0/ 0/0 0/ 0/0 
TSV06 23/0 11/0 14/2 29/0 15/1 10/1 32/13 39/5 20/1 
TSV12 28/0 35/2 23/2 52/16 
CIG 5555667776666 
VIS 5445555555355 
OBVIS NNFNNNNNNFFN 



25 
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0/ 0/0 
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This data provides meteorological measurement data on a 
predetermined interval basis. The above example illustrates 
typical data for the dates of August 26-28 (line 3) on a three 
hour interval basis (line 4). The measurement data of interest 
for the present example includes maximum and minimum 
temperatures (line 6), as well as temperature (line 7), dew- 
point (line 8), cloud characteristics (line 9), wind direction 
(line 10) and speed (line 11) for each of the noted time 
intervals. 

An example of METAR data is: 
SAUS80 KWBC 270000 
METAR 

KCZZ 262348Z AUTO 27008KT 33/12 A2993 RMK A02 
SLP 102 6/ T03330117 10350 20328 56007 PWINO 
TSNO-KJDN 262348Z AUTO 0801 1KT 33/12 A2990 
RMK A02 SLP113 T03280117 20306 56017 PWINO 
TSNO-KP38 282348Z AUTO 16008G16KT 130V200 
34/03 A3000 RMK A02 SLP106 T03390028 10344 
20317 56015 PWINO TSNO-KCDR 262346Z 19014KT 45 
30SM FEW100 BKN120 BKN150 BKN250 33/14 
A2997 

RMK T03270143 12 HR HIGH 37.5 CELSIUS 24 HR 
LOW 15.6 CELSIUS-KART 262348Z 24005KT 7SM 
BKN150 OVC200 20/16 A3005 RMK SLP176 20195 50 
54000- 

It is obvious that this data is far more cryptic and in a form 
and content that does not correspond to the above-noted 
NGM MOS data. The Weather Data Ingest & Assimilation 
System 101 therefore must extract the relevant information 55 
from the various received data streams for use in the 
generation of the requested forecast and outputs assimilated 
data to the Weather information Server 102. 
Weather Information Server 

The Weather Information Server 102, illustrated in addi- 60 
tional detail in FIG. 3, contains all of the data that has been 
ingested and assimilated by the best- in-time forecasting 
system 100. The Weather Information Server 102 accepts the 
assimilated data received from the Weather Data Ingest & 
Assimilation System 101 and provides a set of tools and 65 
systems to facilitate the integration, generation and dissemi- 
nation of the desired weather products and data. The 



Archive Scrubber 303 functions to migrate old data from the 
Data Store 302 to the Archive Store 304, when this data has 
expired or is no longer valid. The Archive Store 304 
represents a history of the input data to enable the best-in- 
time forecasting system 100 to retrieve historic data in the 
forecasting process. 
Presentation Content System 

The Presentation Content System 103, illustrated in addi- 
tional detail in FIG. 4, functions to create the user informa- 
tion by accessing and integrating the data stored in the 
Weather Information Server 102, other information 
providers, and non-weather databases. The Presentation 
Content System 103 comprises a plurality of databases, with 
the Time -Varying Phenomena Characteristic Information 
Database 411 providing a subset of the time-varying char- 
acteristic data that the phenomena forecaster requires to 
process the forecast request. This Time- Varying Phenomena 
Characteristic Information Database 411 contains the previ- 
ously processed results relating to the user-desired time- 
varying phenomena characteristic information. User Prefer- 
ences Database 412 is an optional component of this 
Presentation Content System 103 and functions to record the 
past activity of the user to enable the best-in -time forecast- 
ing system to provide user-customized responses. An Activ- 
ity Database 413 provides information relating to a defini- 
tion of the various activities which are supported by the 
best-in-time time forecasting system 100. The activity data 
notes the time-varying characteristics that are relevant to this 
activity so that the Presentation Content System 103 can 
customize the data stored in the Time-Varying Phenomena 
Characteristic Information Database 411 as a function of the 
event. The integration of the various data stored in these 
databases is effected by the Event Forecast Process 401, 
which operates on the forecast request received from a user 
by retrieving the information from these databases most 
appropriate to generate a forecast to satisfy the user's 
request. An example of the operation of the Event Forecast 
Process 401 is provided below. 
Typical Forecast Information Request 

The present best-in-time forecasting system 100 uses CGI 
calls to transfer data to an interface program that runs on a 
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Network Server 402. CGI is a well-known method for 
providing additional functionality to WEB servers, such as 
Network Server 402. The format for a user request that 
initiates an CGI call is also well defined. The basic CGI 
functionality is presently described on the Internet at the 5 
URL "http://hoohoo.ncsa.uiuc.edu/cgi/interface.html" as 
follows: 
What is CGI? 

CGI is not a language. It's a simple protocol that can be 
used to communicate between WEB forms and your 10 
program. A CGI script can be written in any language 
that can read STDIN, write to STDOUT, and read 
environment variables, i.e. virtually any programming 
language, including C, Perl, or even shell scripting. 
Structure of a CGI Script 15 
Here's the typical sequence of steps for a CGI script: 

1. Read the users form input. 

2. Do what you want with the data. 

3. Write the HTML response to STDOUT. 20 
Reading the User's Form Input 

When the user submits the form, your script receives the 
form data as a set of name-value pairs. The names are 
what you defined in the INPUT tags (or SELECT or 
TEXTAREA tags), and the values are whatever the user 25 
typed in or selected. (Users can also submit files with 
forms, but this primer doesn't cover that.) 

This set of name-value pairs is given to you as one long 
string, which you need to parse. It's not very 
complicated, and there are plenty of existing routines to 30 
do it for you. Here's one in Perl, a simpler one in Perl, 
or one in C. The CGI directory at Yahoo includes many 
CGI routines (and pre- written scripts), in various lan- 
guages. 

If that's good enough for you, skip to the next section. If 35 
you'd rather do it yourself, or if you're just curious, 
here's the format of the long string: 

"name 1 =value 1 & name2=valuc2&na me3=val ue3" 

40 

So just split on the ampersands and equal signs. Then do 
two more things to each name and value: 

1. Convert all "+" characters to spaces, and 

2. Convert all "%xx" sequences to the single character 45 
whose ascii value is "xx'\ in hex. For example, convert 
"%3d" to 

This is needed because the original long string in URL- 
encoded, to allow for equal signs, ampersands, and so 
forth in the user's input. 50 
So where do you get the long string? That depends on the 
HTTP method the form was submitted with: 
For GET submissions, its in the environment variable 

QUERY_STRING. 
For POST submissions, read it from STDIN. The exact 55 
number of bytes to read is in the environment 
variable CONTENT_LENGTH. 
Sending the Response Back to the User 
First, write the line: Content-Type: text/html plus another 
blank line, to STDOUT. After that, write your HTML 60 
response page to STDOUT, and it will be sent to the 
user when your script is done. That's all there is to it. 
FIGS. 5 A and 5B illustrate in flow diagram form the 
processing of a user provided forecast request by the present 
best-in-time forecasting system 100. A user provides the 65 
best-in-time forecasting system 100 with data indicative of 
the time, date, place and type of activity at step 501. 
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Regardless of the information provided by the user, the 
best-in-time forecasting system 100 generates a response 
with the thoroughness and accuracy of the response being a 
function of the specificity of the user-provided information 
and the length of time between the present time and the 
event occurrence. In particular, the user's request stimulates 
the best-in-time forecasting system 100 at step 501A to 
check the Activity Database 413 to determine the particular 
characteristics that are relevant to the selected activity. The 
Event Forecast Process 401 at step 502 identifies the set of 
resources that are available to the best-in-time forecasting 
system 100 that can be used to provide the user-requested 
information. The information can be purely climate data or 
a blending of real-time and forecast data sources. The 
forecast can also be tailored to the specific activity identified 
by the user. The user-provided data caD include threshold 
data which causes the best-in-time forecasting system 100 to 
generate a notification of the user if certain parameters are 
met or exceeded. The best-in-time forecasting system 100 
can then notify the user through some communication 
medium, such as by Network Server 402 transmitting an 
E-Mail message to the user over network 403. The request 
may alternatively originate via user's calendar and sched- 
uling software, project management software, an events 
scheduler or by completing a system provided screen. 

A user requests a forecast for a particular date, time and 
place. Based upon the length of time between the present 
time and the event occurrence, at step 503 the Event 
Forecast Process 401 requests specific information from the 
Weather Information Database 102. The retrieved data are 
integrated, blended and weighted by the Event Forecast 
Process 401 at step 504 to produce the best possible forecast 
from the presently available information. The forecast is 
tailored for the user to match the user's preferences and 
specific weather information needs for the identified event at 
step 505. Finally, the generated forecast is transferred by 
Event Forecast Process 401 to Network Server 402 for 
transmission to the user at step 506 over Network 403. 

Example: A user is planning a trip to a selected city at a 
point in time distant from the present time. The user's event 
scheduling system is set to alert the user if precipitation is 
predicted for the event. The users event scheduling system 
can periodically query the best-in-time forecasting system 
100 to provide the user with the desired information. As the 
event date and time approaches the presently time, the 
specificity and accuracy of the forecast increases. 

In this query process example, the user, identified by the 
user code ID71466, requests the forecast for the desired 
event, comprising a baseball game being played at 10 AM 
tomorrow in Boston, Mass. at Fenway Park. This request is 
made over the Internet to Network Server 402. In the present 
example, this request comprises the data: baseball game, 
Boston, 10 AM tomorrow. This request is sent by the user 
from their data input terminal over the network 403 to the 
web server (Network Server 402). The user request can be 
coded in the following exemplary form: 
/event?userID-71466&rq„type-baseball&station- 

BOS&date-08%2F07%2F97& dlime-lO&name- 

Toronto+at+Boston 

In the best-in-time forecasting system 100, the selection 
of data sources is done based upon the following factors: 

1. The geographic location for which a forecast is desired. 

2. The length of time between the time of the request and 
the time for which a forecast is desired. 

3. The type of activity for which the forecast is intended. 
The decisions made by the Event Forecast Process 401 of 

the best-in- time forecasting system 100 to select the appro- 
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priate data sources to produce a forecast for a baseball game 
are shown in FIG. 5 as: 

How long until the baseball game? (Step 503A) 

If less than two days, then blend data from NGM MOS & 

METAR (Step 503B) 
If between two days and three days, use the data from 

AVN MOS & MFR MOS (Step 503C). 
If between three days and seven days, use MFR MOS data 
(Step 503D). 



information for Boston as noted in the NGNB MOS report. 
The Event Forecaster Process 401 calculates a difference 
between each variable in the two reports for which a forecast 
is requested and calculates a correction factor (CF) based 
upon the amount of time between the time of the last 
METAR report and the time for which the Event Forecast 
Process 401 is forecasting, which is termed time U T\ The 
Event Forecaster Process 401 applies the full correction 
CF=1 if T«3, otherwise, CF=e- fl( *"- 3) , where a is a constant 



If more than seven days, use climatology data (Step 10 that determines the rate at which the amount of correction 



503E) 

In addition to the selection of the type of data, the Activity 
Database 413 defines that if the Event Forecast Process 401 
is forecasting for a baseball game that is scheduled to occur 
in less than two days, then provide a time specific forecast is 
for the first inning (defined as a point in lime with respect to 
the scheduled beginning of the event) and another time 
specific forecast for the nominal end of the event (ninth 
inning — estimated to be three hours after the scheduled 
beginning of the event). The Activity Database 413 also 20 
identifies to the Event Forecast Process 401 that the vari- 
ables that are important to a typical individual attending the 
selected event are: temperature, wind speed and direction, 
relative humidity, cloudiness, chance of precipitation, and 
heat index or wind chill. The Activity Database 413 also 25 
defines the format of the data to be presented to the user, 
such as wind direction should be characterized in terms of its 
orientation with the facility in which the event takes place. 
Thus, instead of an absolute measure of North at 5 mph, the 
present best-in-time forecasting system 100 presents the data 30 
in relative terms such as "out of left field at 5 mph". The 
orientation of the facility is also stored in the Activity 
Database 413. 

In the present example, the two data sources that are 
selected are the most appropriate given the above criteria. 35 
Other data sources that only give a high and low for the day, 
such as the NWS MRF model, or the AN model do not 
contain enough information to forecast for a specific hour of 
the day. There are other sources, which can contribute to a 



decreases over time. The Event Forecaster Process 401 then 
adds the calculated correction to the NGM MOS forecast 
values for the time that the Event Forecast Process 401 is 
forecasting for. 

For the present example: 

1. The present METAR data indicates that the Boston 
temperature at 7 PM is 67 degrees. 

2. The NGM MOS forecast indicates that the temperature 
for Boston at 7 PM was 74 degrees. 

3. The temperature difference is -7 degrees (J di ^-1), 

4. From the NGM MOS forecast indicates that the fore- 
casted temperature for 10 AM tomorrow is 77 degrees 
(J ngm ). 

5. The difference between the last known time 7 PM and 
the time at which we are forecasting is 15 hours. 

6. The following formula, where a =0.770 16353 is used to 
compute the correction factor CF=*T a(13 " 3) =0.397. 

7. The amount of correction is then given by T corr = 
CF'T^-2.78. 

8. The new temperature forecast T WM =T ngm +T co „=74. 
A temperature forecast of 74 degrees is then provided at 

step 506 to the requesting user for a temperature forecast for 
Boston valid at 10 AM tomorrow. The process assimilates 
information from different sources about a single location to 
provide a more accurate forecast than any one by themselves 
could provide. The event based forecast process is capable 
of making decisions based upon the data sources that are 
available and provide some information for any location it 



more accurate forecast, and the inclusion of specific sources 40 knows about for any date and time in the future. 



in the present best-in -time forecasting system represents a 
matter of design choice. The data used in this example is 
obtained from the well known weather sources of National 
Weather Service Family of Services: METAR Surface Data, 
and NGM MOS Data. 

Both data sets are assimilated into a form that can be 
readily placed into the Data Store 302 contained in the 
Weather Information Server 102. New METAR data does 
not always completely outdate previously received METAR 



Similar calculations are performed for the wind, precipi- 
tation probability for the beginning of the game, then the 
process is repeated for the time representative of the end of 
the game. The user ID is also used to retrieved data from the 
45 User Preferences Database 412 that identifies the format of 
the content that is returned to the user. For example, the 
requesting user can be connected over a high bandwidth 
communication connection and the Event Forecast Process 
401 can then present the information to the user in a 



data and the newly received data must therefore be merged 50 graphically intensive display. Similarly, the user can desire 



with the previously received data. NGM MOS data is similar 
in that the newly received data does not always completely 
outdate previously received NGM MOS data. The newly 
received data form both of these sources are assimilated into 
a single record in the Data Store 302. The system also 
interpolates the NGM MOS data from 3 hour intervals, as 
received, into 1 hour intervals. This data receipt, assimila- 
tion and interpolation occur on a continuous basis as data is 
available to ensure that the data stored in the Data Store 302 
is always current. 

The Event Forecaster Process 401 determines that the 
request for the forecast is less than 48 hours from the time 
of the event. Based upon this information, the Event Fore- 
caster Process 401 at step 503B requests the latest METAR 



only a subset of the normally presented information, and this 
"filter factor" can be recorded in the User Preferences 
Database 412 as a result of prior user activity. 
Summary 

55 The present best-in-time forecasting system overcomes 
the problems of the prior art and provides a forecasting 
system that can customize its output forecast to the specific 
needs of a user and an identified event, which forecast is 
optimized as a function of the length of time between the 

60 receipt of the request and the time of the event. In operation, 
a user provides the best-in-time forecasting system with data 
indicative of the time, date, place for the forecast as well as 
the type of activity that the user wishes to participate in on 



the identified time and date. Regardless of the information 
data for the Boston site. The Event Forecaster Process 401 65 provided by the user, the best-in-time forecasting system 
blends the two sets of data by comparing the actual obser- generates a response, with the thoroughness and accuracy of 
vation data in the Boston METAR report with the forecasted the response being a function of the specificity of the 
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user-provided information and the length of time between 
the present time and the event occurrence. The user's request 
stimulates the best-in-time forecasting system to identify the 
set of resources that are available to the best-in-time fore- 
casting system that can be used to provide the user-requested 
information. 

The data sources are not comprehensive, but simply 
illustrative of the Operation of the present best-in-time 
forecasting system in the selected example. While the 
example presented is simple in nature and the data inputs 
and data outputs are relatively fixed, the present best-in-time 
forecasting system can operate in a more dynamic manner 
by the inclusion of a neuromorphic processing element, such 
as an expert system, neural network, fuzzy logic, artificial 
intelligence, decision trees and the like, to review the 
sources of data, nature of the request and then cast an 
appropriate response based upon past experiences and analo- 
gous requests, without the structure of the present example 
being the determining factor. 

We claim: 

1. An information management system for producing a 
weather related information display in response to a user 
specific request for weather information relating to a future 
event comprising: 

means, connected to a plurality of information sources, 
each of which produces at least one weather informa- 
tion element of predetermined content and form and at 
least one of which comprises a substantially real time 
weather information source, for compiling time varying 
weather phenomena characteristic data, said at least 
one information element varying in form and content 
among said plurality of information sources; 

means for enabling a user to input information which 
specifies a user specific request for weather information 
relating to a future event, said information request 
identifying a time and location of said future event; 

means for interpreting said user specific request to iden- 
tify a set of weather information relevant to said future 
event; 

means for identifying said user specific request to identify 40 
at least one of said plurality of information sources in 
which weather information, that is required to respond' 
to said user specific request, resides; 

means, responsive to said interpreting means, for excerpt- 
ing weather information from said at least one infor- 45 
mation source to service said user specific request; and 

means for dynamically compiling said excerpted weather 
information, including weather information from said 
substantially real time weather information source to 
produce a weather forecast of future weather conditions 50 
relating to said future event in response to said user 
specified request. 

2. The apparatus of claim 1 further comprising: 
means for delivering said produced user specified infor- 
mation display to a display device associated with said 55 
requesting user. 

3. The apparatus of claim 2 wherein said delivering means 
comprises a switched communication medium which serves 
a plurality of subscribers. 

4. The apparatus of claim wherein said plurality of 60 
information sources comprises at least one meteorological 
phenomena monitoring system which produces data indica- 
tive of characteristics of at least one meteorological phe- 
nomena monitored by said at least one meteorological 
phenomena monitoring system. 65 

5. The system of claim 1 wherein said means for inter- ' 
preting comprises: 



means for identifying a correspondence between an event 
identified in said user specific information request and 
a set of said plurality of information sources that 
contain data relevant to said user specified information 
display. 

6. The system of claim 5 wherein said means for inter- 
preting further comprises: 

means for identifying a correspondence between said 
event and selected data contained in said set of said 
plurality of information sources. 

7. The system of claim 5 wherein said means for inter- 
preting further comprises: 

means for identifying a correspondence between said 
event and selected data contained in said set of said 
15 plurality of information sources, where said correspon- 
dence is a function of the time difference between 
receipt of said user specific information request and a 
time of occurrence of said event. 

8. The system of claim 1 wherein said means for com- 
20 piling comprises: 

means for identifying a set of presentation preferences of 
said user which define a mode and content of said 
response. 

9. A method of operating an information management 
25 system for producing a weather related information display 

in response to a user specific request for weather information 
relating to a future event comprising the steps of: 

compiling time varying weather phenomena characteristic 
data from a plurality of information sources, each of 
which produces at least one weather information ele- 
ment of predetermined content and form, said at least 
one information element varying in form and content 
among said plurality of information sources and at least 
one of which comprises a substantially real time 
weather information source; 
enabling a user to input information which specifies a user 
specific request for weather information relating to a 
future event, said information request identifying a 
time and location of said future event; 
interpreting said user specific request to identify a set of 

weather information relevant to said future event; 
identifying said user specific request to identify at least 
one of said plurality of information sources in which 
weather information, that is required to respond to said 
user specific request, resides; 
excerpting, in response to said interpreting means, 
weather information from said at least one information 
source to service said user specific request; 
dynamically compiling said excerpted weather 
information, including weather information from said 
substantially real time weather information source, to 
produce a weather forecast of future weather conditions 
relating to said future event in response to said user 
specified request. 

10. The method of claim 9 further comprising the step of: 
delivering said produced user specified information dis- 
play to a display device associated with said requesting 
user. 

11. The method of claim 10 wherein said step of enabling 
comprises activating a bidirectional communication inter- 
face comprising: 

providing a subscriber with apparatus for inputting data 
which defines said user specified information display; 
and 

producing a human sensible display of said user specified 
information display received from said delivery means. 
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12. The method of claim 9 wherein said plurality of 
information sources comprises at least one meteorological 
phenomena monitoring system which produces data indica- 
tive of characteristics of at least one meteorological phe- 
nomena monitored by said at least one meteorological 
phenomena monitoring system, said step of compiling said 
excerpted information comprises: 

generating a weather forecast specific to a user defined 
locus, time and activity. 

13. The method of claim 9 wherein said step of interpret- 
ing comprises: 

identifying a correspondence between an event identified 
in said user specific information request and a set of 
said plurality of information sources that contain data 
relevant to said user specified information display. 

14. The method of claim 13 wherein said step of inter- 
preting further comprises: 
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identifying a correspondence between said event and 
selected data contained in said set of said plurality of 
information sources. 

15. The method of claim 13 wherein said step of inter- 
5 preting further comprises: 

identifying a correspondence between said event and 
selected data contained in said set of said plurality of 
information sources, where said correspondence is a 
function of the time difference between receipt of said 
10 user specific information request and a time of occur- 
rence of said event. 

16. The method of claim 9 wherein said step of compiling 
comprises: 

identifying a set of presentation preferences of said user 
15 which define a mode and content of said response. 

* * * * * 
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